<html>
<head>
<title>jTDS JDBC Driver</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta http-equiv="Keywords" content="jTDS, open source, free JDBC driver, free driver, free, JDBC, JDBC 2.0, JDBC 3.0, driver, type 4, pure Java, SQL Server, Sybase, SQL Server 6.5, SQL Server 7.0, SQL Server 2000, SQL Server 2005, SourceForge">
<link rel="stylesheet" href="style.css" type="text/css">
</head>

<body>
<table class="mainTable" cellpadding="0" cellspacing="0">
  <tr>
    <td colspan="3" class="logoWrapper">
      <table cellpadding="0" cellspacing="0" class="logo">
        <tr>
          <td class="logo"><img src="images/logo.gif" alt="The jTDS Project" class="logo"></td>
          <td class="logo"><img src="images/logoBg.gif" class="logoBg"></td>
        </tr>
      </table>
    </td>
  </tr>
  <tr>
    <td colspan="3">&nbsp;</td>
  </tr>
  <tr>
    <td width="9" height="9"><img src="images/maintl.gif" width="9" height="9"></td>
    <td height="9" background="images/maint.gif"><img src="images/spacer.gif"></td>
    <td width="9" height="9"><img src="images/maintr.gif" width="9" height="9"></td>
  </tr>
  <tr>
    <td width="9" background="images/mainl.gif"><img src="images/spacer.gif"></td>
    <td class="content">
      <p class="links">
        <a href="index.html">Home</a>
        | <span class="selected">FAQ</span>
        | <a href="doc.html">Documentation</a>
        | <a href="links.html">Links</a>
        | <a href="license.html">License</a>
        | <a href="http://sourceforge.net/projects/jtds">Project Info</a>
        | <a href="http://sourceforge.net/projects/jtds/files">Download</a>
        | <a href="http://sourceforge.net/p/jtds/news">News</a>
        | <a href="http://sourceforge.net/p/jtds/bugs">Bugs</a>
        | <a href="http://sourceforge.net/p/jtds/discussion">Forums</a>
      </p>


<!--
==================================
  Content starts here
==================================
-->


      <p class="title">Frequently Asked Questions</p>
      <p class="question">Getting Started</p>
      <ul>
        <li><a href="#driverImplementation">What are the class names of the <code>Driver</code>,
          <code>DataSource</code>, <code>ConnectionPoolDataSource</code>, <code>XADataSource</code>
          and <code>ObjectFactory</code> implementations?</a></li>
        <li><a href="#urlFormat">What is the URL format used by jTDS?</a></li>
        <li><a href="#benchmarks">jTDS is supposed to be the fastest JDBC driver
          around. Have you got any figures to prove that? Or even better, a
          benchmark I can run myself?</a></li>
        <li><a href="#features">Which JDBC features are and which features are
          not supported by jTDS?</a></li>
        <li><a href="#multithreading">Can jTDS be used in a multi threaded
          application?</a></li>
      </ul>
      <p class="question">Error Conditions</p>
      <ul>
        <li><a href="#classNotFound">Why do I get a <code>ClassNotFoundError</code>
          when calling <code>Class.forName(&quot;net.sourceforge.jtds.jdbc.Driver&quot;)</code>?</a></li>
        <li><a href="#noSuitableDriver">Why do I get a <code>java.sql.SQLException:
          &quot;No suitable driver&quot;</code> when trying to get a connection?</a></li>
        <li><a href="#connectionRefused">Why do I get <code>java.sql.SQLException:
          &quot;Network error IOException: Connection refused: connect&quot;</code>
          when trying to get a connection?</a></li>
        <li><a href="#instanceName">Where does one place an instance name in the
          connect string? Connecting with <code>"jdbc:jtds:sqlserver://host\instance:port/database"</code>
          gives an SQLException with the message "Logon failed".</a></li>
        <li><a href="#instanceGetInfo">Why do I get a <code>java.sql.SQLException:
          &quot;Unable to get information from SQL Server&quot;</code> when
          trying to connect to an SQL Server instance?</a></li>
        <li><a href="#windowsAuth">I was hoping that appending <code>";domain=X"</code>
          to the URL would be enough on a workstation that was already logged
          into domain X. Why do I still need to provide a username and password?</a></li>
        <li><a href="#expectingResultSet"><code>executeQuery()</code> throws
          <code>java.sql.SQLException: "The executeQuery method must return a
          result set."</code>.</a></li>
        <li><a href="#forwardOnlyResultSet">I get <code>java.sql.SQLException:
          &quot;ResultSet may only be accessed in a forward direction&quot;</code>
          or <code>&quot;ResultSet is read only&quot;</code> when using a
          scrollable and/or updateable <code>ResultSet</code>.</a></li>
        <li><a href="#sqlStates">Not all <code>SQLException</code>s thrown by
          jTDS seem to have associated meaningful SQL state values.</a></li>
        <li><a href="#batchProcessing">Batch processing with executeBatch()
          hangs or is unreliable on Sybase.</a></li>
      </ul>
      <p class="question">Incorrect Behavior</p>
      <ul>
        <li><a href="#callableStatementOutput"><code>CallableStatement</code>
          output parameter getter throws <code>java.sql.SQLException:
          &quot;Parameter <i>X</i> has not been set.&quot;</code>.</a></li>
        <li><a href="#lastUpdateCount">
          <code>PreparedStatement.executeUpdate()</code> returns an incorrect
          update count.</a></li>
        <li><a href="#badrpccall">Why do I get <code>java.sql.SQLException:
          &quot;Output parameter not allowed
          as argument list prevents use of RPC.&quot;</code>
          when calling a stored procedure?</a></li>
      </ul>
      <p class="question">Memory Usage</p>
      <ul>
        <li><a href="#preparedStatmentMemoryLeak">Memory usage keeps increasing
          when using generated <code>PreparedStatements</code>.</a></li>
      </ul>
      <p class="question">TDS Protocol Version</p>
      <ul>
        <li><a href="#getConnectionHangs">I'm trying to connect to SQL Server
          6.5, but it hangs when calling <code>getConnection()</code>.</a></li>
        <li><a href="#longColumnNames">Why do column names more than 30 characters
          long, get chopped off at 30 characters?</a></li>
        <li><a href="#imageData4k">jTDS fetches only the first 4Kb of <code>IMAGE</code>
          data.</a></li>
        <li><a href="#connectOmnibus">What do i have to do to connect to Netcool Omnibus 
          (or any derived Product).</a></li>
      </ul>
      <p class="question">Technical Support</p>
      <ul>
        <li><a href="#techSupport">Is there any commercial
          technical support available for jTDS?</a></li>
      </ul>
      <p class="question">Other</p>
      <ul>
        <li><a href="#other">I didn't find the answer to my problem in this
          FAQ. What should I do?</a></li>
      </ul>

      <p class="title">Getting Started</p>
      <p class="question"><a name="driverImplementation"></a>What are the class names of the <code>Driver</code>,
          <code>DataSource</code>, <code>ConnectionPoolDataSource</code>, <code>XADataSource</code> and
          <code>ObjectFactory</code> implementations?</p>
      <table class="inner" cellpadding="0" cellspacing="0">
        <thead>
          <tr><th>Interface</th><th>jTDS Implementation</th></tr>
        </thead>
        <tbody>
          <tr><td><code>java.sql.Driver</code></td><td><code>net.sourceforge.jtds.jdbc.Driver</code></td></tr>
          <tr><td><code>javax.sql.DataSource</code></td><td><code>net.sourceforge.jtds.jdbcx.JtdsDataSource</code></td></tr>
          <tr><td><code>javax.sql.ConnectionPoolDataSource</code></td><td><code>net.sourceforge.jtds.jdbcx.JtdsDataSource</code></td></tr>
          <tr><td><code>javax.sql.XADataSource</code></td><td><code>net.sourceforge.jtds.jdbcx.JtdsDataSource</code></td></tr>
          <tr><td><code>javax.naming.spi.ObjectFactory</code></td><td><code>net.sourceforge.jtds.jdbcx.JtdsObjectFactory</code></td></tr>
        </tbody>
      </table>
      <p><a href="#">^ top ^</a></p>
      <p class="question"><a name="urlFormat"></a>What is the URL format used
        by jTDS?</p>
      <p>The URL format for jTDS is:</p>
      <pre>    jdbc:jtds:&lt;server_type&gt;://&lt;server&gt;[:&lt;port&gt;][/&lt;database&gt;][;&lt;property&gt;=&lt;value&gt;[;...]]</pre>
      <p>where <code>&lt;server_type&gt;</code> is one of either <code>'sqlserver'</code>
        or <code>'sybase'</code> (their meaning is quite obvious), <code>&lt;port&gt;</code>
        is the port the database server is listening to (default is 1433 for SQL
        Server and 7100 for Sybase) and <code>&lt;database&gt;</code> is the database
        name -- JDBC term: catalog -- (if not specified, the user's default database
        is used). The set of properties supported by jTDS is:</p>
      <dl>
        <dt><code>appName</code> (default - <code>&quot;jTDS&quot;</code>)</dt>
        <dd>Application name. No practical use, it's displayed by Enterprise Manager
          or Profiler associated with the connection.</dd>
        <dt><code>autoCommit</code> (default - <code>&quot;true&quot;</code>)</dt>
        <dd>Auto Commit. The jTDS driver enables auto commit by default. Use this option to 
        	disable auto commit for newly created connections.</dd>
        <dt><code>batchSize</code> (default - <code>0</code> for SQL Server;
          <code>1000</code> for Sybase)</dt>
        <dd>Controls how many statements are sent to the server in a batch.
          The actual batch is broken up into pieces this large that are sent
          separately. The reason for this is to avoid Sybase "hangs" caused by
          running out of space with very large batches. The problem doesn't
          seem to occur with SQL Server, hence the default limit of 0
          (unlimited) in this case.</dd>
        <dt><code>bindAddress</code> (default - determined by the Java
          implementation)</dt>
        <dd>Specifies the local IP address to bind to for outgoing TCP/IP
          connections to the database.  Useful for multi-homed systems (those with
          more than one external IP address) where the default IP address picked by
          Java will not connect to the database.  Currently has no effect when
          using named pipes to connect to a database (see
          <code>namedPipe</code>).</dd>
        <dt><code>bufferDir</code> (default - <code>System.getProperty("java.io.tmpdir")</code>)</dt>
        <dd>Controls the destination where data is buffered to disk.<br/>
          See also <code>bufferMaxMemory</code> and <code>bufferMinPackets</code>.</dd>
        <dt><code>bufferMaxMemory</code> (default - <code>1024</code>)</dt>
        <dd>Controls the global buffer memory limit for all connections (in
          kilobytes). When the amount of buffered server response packets
          reaches this limit additional packets are buffered to disk; there is
          however one exception: each <code>Statement</code> gets to buffer at
          least <code>&lt;bufferMinPackets&gt;</code> to memory before this
          limit is enforced. This means that this limit can and will usually be
          exceeded.<br/>
          Server responses are buffered to disk only when a request is made on
          a <code>Statement</code> while another <code>Statement</code>
          belonging to the same Connection still hasn't processed all its
          results. These situations can be avoided in most cases by setting the
          <code>useCursors</code> property, but this will also affect
          performance.<br/>
          See also <code>bufferMinPackets</code>.</dd>
        <dt><code>bufferMinPackets</code> (default - <code>8</code>)</dt>
        <dd>Controls the minimum number of packets per statement to buffer to
          memory. Each <code>Statement</code> will buffer at least this many
          packets before being forced to use a temporary file if the
          <code>&lt;bufferMaxMemory&gt;</code> is reached, to ensure good
          performance even when one <code>Statement</code> caches a very large
          amount of data.<br/>
          Server responses are buffered to disk only when a request is made on
          a <code>Statement</code> while another <code>Statement</code>
          belonging to the same Connection still hasn't processed all its
          results. These situations can be avoided in most cases by setting the
          <code>useCursors</code> property, but this will also affect
          performance.<br/>
          See also <code>bufferMaxMemory</code>.</dd>
        <dt><code>cacheMetaData</code> (default - <code>false</code>)</dt>
        <dd>When used with prepareSQL=3, setting this property to
          <code>true</code> will cause the driver to cache column meta data for
          SELECT statements. Caching the meta data will reduce the processing
          overhead when reusing statements that return small result sets that
          have many columns but may lead to unexpected errors if the database
          schema changes after the statement has been prepared. Use with care.
          Only applicable to SQL Server (there is no prepareSQL=3 mode for
          Sybase).
        <dt><code>charset</code> (default - the character set the server was installed
          with)</dt>
        <dd>Very important setting, determines the byte value to character mapping
          for <code>CHAR</code>/<code>VARCHAR</code>/<code>TEXT</code> values.
          Applies for characters from the extended set (codes 128-255). For
          <code>NCHAR</code>/<code>NVARCHAR</code>/<code>NTEXT</code> values
          doesn't have any effect since these are stored using Unicode.</dd>
        <dt><code>domain</code></dt>
        <dd>Specifies the Windows domain to authenticate in. If present and the
          user name and password are provided, jTDS uses Windows (NTLM)
          authentication instead of the usual SQL Server authentication (i.e.
          the user and password provided are the domain user and password).
          This allows non-Windows clients to log in to servers which are only
          configured to accept Windoes authentication.<br/>
          If the <code>domain</code> parameter is present but no user name and
          password are provided, jTDS uses its native Single-Sign-On library
          and logs in with the logged Windows user's credentials (for this to
          work one would obviously need to be on Windows, logged into a domain,
          and also have the SSO library installed -- consult README.SSO in the
          distribution on how to do this).</dd>
        <dt><code>instance</code></dt>
        <dd>Named instance to connect to. SQL Server can run multiple so-called
          "named instances" (i.e. different server instances, running on different
          TCP ports) on the same machine. When using Microsoft tools, selecting
          one of these instances is made by using "&lt;host_name&gt;\&lt;instance_name&gt;"
          instead of the usual "&lt;host_name&gt;". With jTDS you will have to
          split the two and use the instance name as a property.</dd>
        <dt><code>lastUpdateCount</code> (default - <code>true</code>)</dt>
        <dd>If <code>true</code> only the last update count will be returned by
          <code>executeUpdate()</code>. This is useful in case you are updating
          or inserting into tables that have triggers (such as replicated tables);
          there's no way to make the difference between an update count returned
          by a trigger and the actual update count but the actual update count
          is always the last as the triggers execute first. If <code>false</code>
          all update counts are returned; use <code>getMoreResults()</code> to
          loop through them.</dd>
        <dt><code>lobBuffer</code> (default - <code>32768</code>)</dt>
        <dd>The amount of LOB data to buffer in memory before caching to disk. The
          value is in bytes for <code>Blob</code> data and chars for <code>Clob</code>
          data.</dd>
        <dt><code>loginTimeout</code> (default - <code>0</code> for TCP/IP connections
          or <code>20</code> for named pipe connections)</dt>
        <dd>The amount of time to wait (in seconds) for a successful connection
          before timing out.<br/>
          If a TCP/IP connection is used to connect to the database, the <code>loginTimeout</code> parameter is used to set
          the initial connection timeout when initially opening a new socket.  A value
          of zero (the default) causes the connection to wait indefinitely, e.g.,until
          a connection is established or an error occurs.  See also
          <code>socketTimeout</code>.<br/>
          If a named pipe connection is used (<code>namedPipe</code> is
          <code>true</code>) and <code>loginTimeout</code> is greater than zero, the
          value of <code>loginTimeout</code> is used for the length of the retry period
          when "All pipe instances are busy" error messages are received while
          attempting to connect to the server.  If <code>loginTimeout</code> is zero
          (the default), a value of 20 seconds is used for the named pipe retry
          period.</dd>
        <dt><code>macAddress</code> (default - real MAC address if available, otherwise <code>"000000000000"</code>)</dt>
        <dd>Network interface card MAC address. It's displayed by Enterprise
          Manager or Profiler associated with the connection and is needed to
          resolve some issues regarding the number of clients allowed by the
          SQL Server license. The MAC address is determined automatically from
          the network interface used to connect the server (or a random non-loopback
          network interface if using named pipes to connect to a database).</dd>
        <dt><code>maxStatements</code> (default - <code>500</code>)</dt>
        <dd>The number of statement prepares each connection should cache.
          A value of <code>0</code> will disable statement caching.
          A value of <code>Integer.MAX_VALUE</code> (<code>2147483647</code>)
          will enable fast caching (uses less memory and has no overhead
          associated with removing statements); the cache will never release
          any cached statements, so although experience has shown that this is
          usually not a problem with most applications, use with care.</dd>
        <dt><code>namedPipe</code> (default - <code>false</code>)</dt>
        <dd>When set to <code>true</code>, named pipe communication is used to
          connect to the database instead of TCP/IP sockets. When the
          <code>os.name</code> system property starts with "windows"
          (case-insensitive), named pipes (both local and remote) are accessed
          through the Windows filesystem by opening a <code>RandomAccessFile</code>
          to the path. When the SQL Server and the client are on the same machine,
          a named pipe will usually have better performance than TCP/IP sockets
          since the network layer is eliminated. Otherwise the
          <a href="http://jcifs.samba.org/">JCIFS</a> library is used. JCIFS
          provides a pure Java named pipe implementation and uses NTLM
          authentication, so the <code>domain</code> parameter is required.<br/>
          This feature supports the <code>instance</code> parameter (which changes
          the named pipe URL), but it does not currently support the named pipe at
          a location other than <code>/sql/query</code> on the server. The
          <code>port</code> parameter is ignored if set.</dd>
        <dt><code>packetSize</code> (default - <code>4096</code> for TDS 7.0/8.0;
          <code>512</code> for TDS 4.2/5.0)</dt>
        <dd>The network packet size (a multiple of 512).</dd>
        <dt><code>password</code> (required)</dt>
        <dd>Password to use for login. When using <code>getConnection(String url,
          String user, String password)</code> it's not required to set this property
          as it is passed as parameter, but you will have to set it when using
          <code>getConnection(String url, Properties info)</code> or <code>JtdsDataSource</code>.</dd>
        <dt><code>prepareSQL</code> (default - <code>3</code> for SQL Server,
          <code>1</code> for Sybase)</dt>
        <dd>This parameter specifies the mechanism used for Prepared Statements.
          <table class="inner" cellpadding="0" cellspacing="0">
            <thead>
              <tr><th>Value</th><th>Description</th></tr>
            </thead>
            <tbody>
              <tr><td><code>0</code></td><td>SQL is sent to the server each time without any preparation, literals are inserted in the SQL (slower)</td></tr>
              <tr><td><code>1</code></td><td>Temporary stored procedures are created for each unique SQL statement and parameter combination (faster)</td></tr>
              <tr><td><code>2</code></td><td>sp_executesql is used (fast)</td></tr>
              <tr><td><code>3</code></td><td>sp_prepare and sp_cursorprepare are used in conjunction with sp_execute and sp_cursorexecute (faster, SQL Server only)</td></tr>
            </tbody>
          </table>
        </dd>
        <dt><code>progName</code> (default - <code>&quot;jTDS&quot;</code>)</dt>
        <dd>Client library name. No practical use, it's displayed by Enterprise
          Manager or Profiler associated with the connection.</dd>
        <dt><code>processId</code> (default - <code>123</code>)</dt>
        <dd>The client process ID associated with the connection. Must be an integer
        value or the string "compute" to let jTDS choose a process ID.</dd>
        <dt><code>sendStringParametersAsUnicode</code> (default - <code>true</code>)</dt>
        <dd>Determines whether string parameters are sent to the SQL Server database
          in Unicode or in the default character encoding of the database. This
          seriously affects SQL Server 2000 performance since it does not automatically
          cast the types (as 7.0 does), meaning that if a index column is Unicode
          and the string is submitted using the default character encoding (or
          the other way around) SQLServer will perform an index scan instead of
          an index seek. For Sybase, determines if strings that cannot be encoded in
          the server's charset are sent as unicode strings. There is a performance
          hit for the encoding logic so set this option to false if unitext or univarchar
          data types are not in use or if charset is utf-8.</dd>
        <dt><code>socketTimeout</code> (default - <code>0</code>)</dt>
        <dd>The amount of time to wait (in seconds) for a server response before timing out.<br/>
          Use with care! If a non zero value is supplied this must be greater than the maximum
          time that the server will take to answer any query. Once the timeout value is exceeded
          the network or named pipe connection will be closed. This parameter may be useful for
          detecting dead network connections in a pooled environment.  See also
          <code>loginTimeout</code>. If using named pipes via JCIFS the timeout cannot be
          disabled completely. A timeout of about 25 days (2^31 ms) is applied instead.</dd>
        <dt><code>socketKeepAlive</code> (default - <code>false</code>)</dt>
        <dd>true to enable TCP/IP keep-alive messages</dd>
        <dt><code>ssl</code> (default - <code>off</code>)</dt>
        <dd>Specifies if and how to use SSL for secure communication.
          <table class="inner" cellpadding="0" cellspacing="0">
            <thead>
              <tr><th>Value</th><th>Description</th></tr>
            </thead>
            <tbody>
              <tr><td><code>off</code></td><td>SSL is not request or used; this is the default</td></tr>
              <tr><td><code>request</code></td><td>SSL is requested; if the server does not support it then a plain connection is used</td></tr>
              <tr><td><code>require</code></td><td>SSL is requested; if the server does not support it then an exception is thrown</td></tr>
              <tr><td><code>authenticate</code></td><td>Same as <code>require</code> except the server's certificate must be signed by a trusted CA</td></tr>
            </tbody>
          </table>
        </dd>
        <dt><code>tcpNoDelay</code> (default - <code>true</code>)</dt>
        <dd><code>true</code> to enable TCP_NODELAY on the socket;
          <code>false</code> to disable it.</dd>
        <dt><code>TDS</code> (default - <code>&quot;8.0&quot;</code> for SQL Server;
          <code>&quot;5.0&quot;</code> for Sybase)</dt>
        <dd>The version of TDS to be used. TDS (Tabular Data Stream) is the protocol
          used by Microsoft SQL Server and Sybase to communicate with database
          clients. jTDS can use TDS 4.2, 5.0, 7.0 and 8.0. Version 4.2 is used by
          SQL Server 6.5 and Sybase 10.  Version 5.0 is used with Sybase 11 onwards.
          Version 7.0 is used by SQL Server 7.0; this protocol also works with SQL
          Server 2000. Version 8.0 is used by SQL Server 2000 and SQL Server 2005.<br>
          Newer database server versions usually understand older protocol versions.
          This means that SQL Server 7.0 can be used with TDS 4.2, but the limitations
          of the protocol apply regardless of the server version (e.g. when using TDS
          4.2 <code>VARCHAR</code>s are limited to 255 characters). As a conclusion,
          you must set this property to <code>&quot;4.2&quot;</code> when connecting
          to SQL Server 6.5 or Sybase.  You should not set this value to
          <code>&quot;7.0&quot; or &quot;8.0&quot;</code>) when connecting to any
          version of Sybase as these are SQL Server specific protocols.  Further, you
          should not set this value to <code>&quot;5.0&quot;</code>) when connecting
          to any version of SQL Server as this is a Sybase specific protocol.<br/>
          Currently jTDS automatically falls back from 8.0 to 7.0 (if used with
          SQL Server 7.0) and from 5.0 to 4.2 (with Sybase 10) so specifying
          the value for this parameter is only necessary for SQL Server 6.5.</dd>
        <dt><code>useCursors</code> (default - <code>false</code>)</dt>
        <dd>Instructs jTDS to use server side cursors instead of direct selects
          (AKA firehose cursors) for forward-only read-only result sets (with
          other types of result sets server- or client-side cursors are always
          used).<br/>
          With firehose cursors the SELECT query is sent and the server
          responds with all the resulting rows. This is the fastest approach
          but it means that the driver has to cache all results if another
          request needs to be made before all rows have been processed. So when
          using multiple <code>Statement</code>s per <code>Connection</code> it
          is preferable to have server-side cursors instead; these will allow
          the driver to request only a limited number of rows at a time
          (controllable through the <code>fetchSize</code> property of a
          <code>Statement</code>). This means extra request-response cycles,
          but less caching by the driver.<br/>
          With SQL Server a so called
          <a href="http://msdn.microsoft.com/library/en-us/acdata/ac_8_con_07_3tdf.asp">fast
          forward-only cursor</a> will be created when this property is set to
          <code>true</code>. With Sybase a usual forward-only read-only cursor
          is created.</dd>
        <dt><code>useJCIFS</code> (default - <code>false</code>)</dt>
        <dd>Controls whether the <a href="http://jcifs.samba.org/">jCIFS</a>
          library will be used instead of the local file system with named pipe
          connections on the Windows operating system.  (The jCIFS library will
          always be used with named pipes when the operating system is not
          Windows.)  Useful when connecting via named pipes to a server that is
          located in a different domain than the client.  See also
          <code>namedPipe</code>.</dd>
        <dt><code>useLOBs</code> (default - <code>true</code>)</dt>
        <dd>Controls whether large types (IMAGE and TEXT/NTEXT) should be
          mapped by default (when using <code>getObject()</code>) to LOBs or
          Java types (<code>String</code> and <code>byte[]</code>). The default
          JDBC type constant returned is also controlled by this property:
          <code>Types.BLOB</code> for IMAGE and <code>Types.CLOB</code> for
          TEXT/NTEXT when <code>true</code>, <code>Types.LONGVARBINARY</code>
          for IMAGE and <code>Types.LONGVARCHAR</code> for TEXT/NTEXT when
          <code>false</code>.<br/>
          This is useful when printing out directly the values returned by
          <code>getObject()</code> (e.g. when using JSTL or other frameworks),
          as <code>Blob</code> and <code>Clob</code> don't implement
          <code>toString()</code> (both because it's not required and because
          it can easily lead to <code>OutOfMemoryError</code>s in unexpected
          situations, such as when logging data). The default setting of
          <code>true</code> has the advantage that the amount of data that is
          cached in memory for a large object can be controlled via the
          <code>lobBuffer</code> property; a setting of <code>false</code> will
          still use the <code>Blob</code> and <code>Clob</code> implementations
          internally but the values will be materialized to memory when
          <code>getObject()</code> is called, possibly leading to memory
          issues.</dd>
        <dt><code>useNTLMv2</code> (default - false)</dt>
        <dd>Set to <code>true</code> to send LMv2/NTLMv2 responses when using
          Windows authentication</dd>
        <dt><code>user</code> (required)</dt>
        <dd>User name to use for login. When using <code>getConnection(String
          url, String user, String password)</code> it's not required to set this
          property as it is passed as parameter, but you will have to set it when
          using <code>getConnection(String url, Properties info)</code> or
          <code>JtdsDataSource</code>.</dd>
        <dt><code>wsid</code> (default - the client host name)</dt>
        <dd>Workstation ID. No practical use, it's displayed by Enterprise
          Manager or Profiler associated with the connection.</dd>
        <dt><code>xaEmulation</code> (default - <code>true</code>)</dt>
        <dd>When set to <code>true</code>, emulate XA distributed transaction
          support, when set to <code>false</code> use experimental true
          distributed transaction support. True distributed transaction support
          is only available for SQL Server 2000 and requires the installation
          of an external stored procedure in the target server (see the
          README.XA file in the distribution for details).</dd>
      </dl>
      <p>Properties can be passed to jTDS in one of three ways: in the URL, in
        the <code>Properties</code> object passed to <code>getConnection()</code>
        or by using the <code>JtdsDataSource</code>'s setters (if connections are
        obtained through a <code>DataSource</code> rather than using the
        <code>DriverManager</code>). Because there is no URL when using the
        <code>JtdsDataSource</code> there are three other properties (with
        setters and getters) to take the place of those items that are part of
        the URL's syntax: <code>serverName</code>, <code>portNumber</code> and
        <code>databaseName</code> (their meaning should be quite clear).</p>
      <p><a href="#">^ top ^</a></p>
      <p class="question"><a name="benchmarks"></a>jTDS is supposed to be the
        fastest JDBC driver around. Have you got any figures to prove that? Or
        even better, a benchmark I can run myself?</p>
      <p>Actually we do have benchmark results from two different benchmarks,
        both developed by large commercial SQL Server JDBC driver vendors to
        demonstrate the performance of their own drivers. In our oppinion this
        is better than having a benchmark of our own, which could be designed
        in such a way as to give jTDS the edge. These benchmarks are free to
        download so we encourage you to do it and run them yourself.</p>
      <p>We have benchmarked jTDS against the two most used commercial drivers
        and of course the Microsoft driver and the JDBC-ODBC bridge, using these
        benchmarks:
        <a href="http://www.inetsoftware.de/English/Produkte/OPTA/Benchmark.htm">i-net
        software's BenchTest 2.1 for MS SQL Server</a> and
        <a href="http://www.jnetdirect.com/downloads.php?op=performsuite">JNetDirect's
        JDBC Performance Benchmark</a>. Here are the results of the i-net test:
        <a href="benchTest.html">BenchTest 2.1 for MS SQL Server</a>. The JNetDirect
        license precludes publication of performance test results. However, you
        can run any of the benchmarks yourself, the effort is minimal.</p>
      <p><a href="#">^ top ^</a></p>
      <p class="question"><a name="features"></a>Which JDBC features are and
        which features are not supported by jTDS?</p>
      <p>jTDS offers full support for all JDBC 3.0 features:
        <a href="resultSets.html">forward-only and scrollable/updateable result
        sets</a>, batch updates, prepared and callable
        statements, unlimited number of statements per connection, complete
        database and result set meta data, and a <code>DataSource</code>
        implementation (which also implements <code>ConnectionPoolDataSource</code>
        and <code>XADataSource</code>). Features such as generated keys
        retrieval, named stored procedure parameters, and save points are also
        implemented.</p>
      <p>The only major features missing from jTDS are connection pooling and
        row sets; the reason for leaving these out is that there are free
        implementations available, probably much better than anything we could
        come up with. Check out the jTDS <a href="features.html">feature
        matrix</a> for more details.</p>
      <p><a href="#">^ top ^</a></p>
      <p class="question"><a name="multithreading"></a>Can jTDS be used in a
        multi threaded application?</p>
      <p>As a general principle we try and keep synchronization to a minimum
        both for performance and deadlock reasons. The only part of jTDS we
        guarantee is thread safe is the <code>Connection</code> object, and
        multi threaded access to <code>Statement</code>s is discouraged (except
        for issuing cancels).</p>
      <p>As a conclusion the only safe multithreading scenarios are these: (i)
        one <code>Connection</code> with multiple <code>Statement</code>s, each
        <code>Statement</code> used by a single thread and (ii) a
        <code>Statement</code> used by one thread and cancelled by some other
        thread. Scenario (i), while it does work, is not necessarily a good
        solution because it requires a lot of locking and waiting on the same
        network connection plus (last but not least) a lot of caching.
      <p><a href="#">^ top ^</a></p>

      <p class="title">Error Conditions</p>
      <p class="question"><a name="classNotFound"></a>Why do I get a
        <code>ClassNotFoundError</code> when calling
        <code>Class.forName(&quot;net.sourceforge.jtds.jdbc.Driver&quot;)</code>?</p>
      <p><code>ClassNotFoundError</code> is thrown by the classloader when it
        can not find a certain class. In this case it's the
        <code>net.sourceforge.jtds.jdbc.Driver</code> class, which means that
        <code>jtds.jar</code> is not in the classpath. If you are getting this
        in an application, start your application with</p>
      <pre>    java -cp &lt;path_to_jtds&gt;/jtds.jar &lt;main_class&gt;</pre>
      <p>If you experience this problem in a servlet/JSP you will have to add
        <code>jtds.jar</code> to your web application's class path (e.g. by
        editing the application's web.xml file or by copying the jar into the
        application's/server's <code>/lib</code> directory).</p>
      <p><b>Note:</b> The name of the jTDS jar file may be <code>jtds-1.2.jar</code>
        or something similar. If that's the case, replace <code>jtds.jar</code>
        in the above example with <code>jtds-1.2.jar</code> or whatever your specific
        file name is.</p>
      <p><a href="#">^ top ^</a></p>
      <p class="question"><a name="noSuitableDriver"></a>Why do I get a <code>java.sql.SQLException:
        &quot;No suitable driver&quot;</code> when trying to get a connection?</p>
      <p>The <code>&quot;No suitable driver&quot;</code> exception is thrown by
        the <code>DriverManager</code> when none of the registered <code>Driver</code>
        implementations recognizes the supplied URL. This means that you either
        did not register jTDS with the <code>DriverManager</code> first (by calling
        <code>Class.forName(&quot;net.sourceforge.jtds.jdbc.Driver&quot;)</code>)
        or you mistyped the URL (e.g. <code>&quot;jbdc:jtds:...&quot;</code>
        instead of <code>&quot;jdbc:jtds:...&quot;</code>).</p>
      <p>A common mistake is to append a semicolon (";") to the end of the URL
        (e.g. <code>"jdbc:jtds:sqlserver://server/db;TDS=7.0;"</code> is wrong!).
      <p>For more information about URL format and the properties that may be
        passed to jTDS have a look at the <a href="#urlFormat">jTDS URL format</a>.</p>
      <p><a href="#">^ top ^</a></p>
      <p class="question"><a name="connectionRefused"></a>Why do I get
        <code>java.sql.SQLException: &quot;Network error IOException: Connection
        refused: connect&quot;</code> when trying to get a connection?</p>
      <p>The <code>&quot;Connection refused&quot;</code> exception is thrown by
        jTDS when it is unable to connect to the server. There may be a number
        of reasons why this could happen:</p>
      <ol>
        <li>The server name is misspelled or the port number is incorrect.</li>
        <li>SQL Server is not configured to use TCP/IP. Either enable TCP/IP
          from SQL Server's Network Utility app or have jTDS connect via named
          pipes (see the <a href="#urlFormat">URL format</a> for information on
          how to do this).</li>
        <li>There is a firewall blocking port 1433 on the server.</li>
      </ol>
      <p>To check whether TCP/IP is enabled and the port is not blocked you can
        use "telnet &lt;server_host&gt; 1433". Until telnet doesn't connect,
        jTDS won't either. If you can't figure out why, ask your network
        administrator for help.</p>
      <p><a href="#">^ top ^</a></p>
      <p class="question"><a name="instanceName"></a>Where does one place an instance
        name in the connect string? Connecting with
        <code>"jdbc:jtds:sqlserver://host\instance:port/database"</code> gives an
        SQLException with the message "Logon failed".
      <p>You will have to use the <code>instance</code> property (either append it to the
        URL or place it into the <code>Properties</code> you supply to <code>getConnection</code>)
        instead of doing it the Microsoft way. Sorry, but jTDS (and its ancestor
        FreeTDS) existed a long time before named instances so the URL could not
        be changed (and using it this way confuses the URL parser).
      <p><a href="#">^ top ^</a></p>
      <p class="question"><a name="instanceGetInfo"></a>Why do I get a
        <code>java.sql.SQLException: &quot;Unable to get information from SQL
        Server&quot;</code> when trying to connect to an SQL Server instance?</p>
      <p>The exception you are getting is usually caused by a timeout. When
        connecting to named instances jTDS needs to connect via UDP to port 1434
        to get information about available SQL Server instances. While doing
        this it times out, throwing the exception you see (which means that jTDS
        was not able to get information about the running instances).</p>
      <p>Connection timeouts occur when there is no server listening on the port
        (BTW, are you sure your SQL Server is configured to use TCP/IP and that
        you actually use named instances?).</p>
      <p>On SQL Server 2005 the SQL Browser service must be running on the
        server host as the instance name lookup port UDP 1434 is hosted by this
        service on SQL Server 2005 rather than the SQL Server itself. The
        default install does not configure the SQL Browser service to start
        automatically so you must do it manually.</p>
      <p><a href="#">^ top ^</a></p>
      <p class="question"><a name="windowsAuth"></a>I was hoping that appending
        <code>";domain=X"</code> to the URL would be enough on a workstation that
        was already logged into domain X. Why do I still need to provide a username
        and password?</p>
      <p>jTDS is a type 4 (pure Java) JDBC driver. This means (among other things)
        that it cannot access platform-specific features, such as determining the
        currently logged user and his credentials. jTDS is distributed with a
        native library (DLL) for Single-Sign-On support, but that only works on
        Windows (please consult README.SSO in the distribution package for
        information on how to install it).</p>
      <p>Without the native SSO library installed you still have to provide the
        username and password because otherwise jTDS cannot determine user
        credentials. There is a good side to this: users on non-Windows
        platforms are able to log in using Windows credentials by providing
        them in the URL, along with the domain name.</p>
      <p><a href="#">^ top ^</a></p>
      <p class="question"><a name="expectingResultSet"></a>
        <code>executeQuery()</code> throws <code>java.sql.SQLException: "The
        executeQuery method must return a result set."</code>.</p>
      <p>The <a href="http://java.sun.com/products/jdbc/download.html">JDBC
        spec</a> and
        <a href="http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Statement.html#executeQuery(java.lang.String)">API
        documentation</a> for <code>Statement</code> both state that
        <code>executeQuery()</code> is intended to be used with queries that
        return a <code>ResultSet</code>, typically <code>SELECT</code>
        statements. On the the other hand, <code>executeUpdate()</code> is
        intended for <code>INSERT</code>, <code>UPDATE</code>,
        <code>DELETE</code> or DDL statements that return update counts. Both of
        these (<code>ResultSets</code> and update counts) are considered by JDBC
        to be "results". For queries that return multiple results the JDBC spec
        requires <code>execute()</code> to be used.</p>
      <p>If you'll look at the query you are trying to execute, you'll see that
        it probably returns an update count first, followed by a
        <code>ResultSet</code>. So according to the JDBC spec you should use
        <code>execute()</code> to run it, call <code>getMoreResults()</code> to
        skip the update count and then call <code>getResultSet()</code> to
        obtain the <code>ResultSet</code> you want.</p>
      <p>As a sidenote, The Microsoft driver (and probably the others, too)
        "optimize" this behavior by skipping over the update count, which is
        wrong according to the JDBC spec. So, for maximum compatibility, it is
        recommended that you use <code>execute()</code> anytime you run queries
        returning more than one result even if the particular driver you are
        using allows you to do otherwise.</p>
      <p>The same thing happens with the ODBC SQL driver and other connectors.
        A common solution rather than the inelegant execute() and then cycling
        through multiple result sets, is to supress the update counts for
        statements you are uninterested in. This is common if say you are
        querying a stored procedure that creates a temp table, runs updates
        against it and then returns the table as a result set. You can
        suppress all the extra "query results" by specifying "<code>SET NOCOUNT
        ON</code>".</p>
      <p><a href="#">^ top ^</a></p>
      <p class="question"><a name="forwardOnlyResultSet"></a>I get
        <code>java.sql.SQLException: &quot;ResultSet may only be accessed in a
        forward direction&quot;</code> or <code>&quot;ResultSet is read
        only&quot;</code> when using a scrollable/updateable
        <code>ResultSet</code>.</p>
      <p>There are three possible causes to this (if we exclude not creating
        the <code>ResultSet</code> with the appropriate type and concurrency in
        the first place):</p>
      <ol>
        <li>The executed query must be a single SELECT statement or a call to a
          procedure that consists of a single SELECT statement (even a SET or
          PRINT will cause the resulting ResultSet to be forward only read
          only). This is a SQL Server limitation and there's not much jTDS can
          do about it.</li>
        <li>The scroll insensitive/updateable combination is not supported by
          SQL Server, so such a <code>ResultSet</code> is automatically
          downgraded to scroll insensitive/read-only by the server. Use the
          scroll sensitive/updateable combination and it should work.</li>
        <li>The other possible cause is that the cursor is keyset-based and
          either the table you are selecting from does not have a unique primary
          key or that primary key is not included in your <code>SELECT</code>.
          See the
          <a href="http://msdn.microsoft.com/library/en-us/acdata/ac_8_con_07_66sz.asp">SQL
          Server Documentation on cursor types</a> for more information.</li>
      </ol>
      <p>In both cases if you call <code>Statement.getWarnings()</code> right
        after calling <code>executeQuery()</code> you'll get a warning about the
        <code>ResultSet</code> being downgraded. Also, please take a look at
        our <a href="resultSets.html"><code>ResultSet</code> support page</a>
        for some additional information and tips.</p>
      <p><a href="#">^ top ^</a></p>
      <p class="question"><a name="sqlStates"></a>Not all
        <code>SQLException</code>s thrown by jTDS seem to have associated
        meaningful SQL state values.</p>
      <p>Indeed, some SQLExceptions are reported with a correct state code
        and some not. As the server itself does not return an SQL state code,
        the SQLMessage class associates native error numbers with SQL state
        codes (actually there's a very comprehensive map there); SQL Server
        originated errors and warnings that are not found in this map are given
        a default code of 'S1000', respectively '01000'. This is what happens
        with SQL Server-returned errors and warnings and is consistent with how
        other drivers handle exceptions. We have done our best to map as many
        errors and warnings, however if you find some case in which other JDBC
        or ODBC drivers return specific SQL states and jTDS doesn't or jTDS
        returned SQL states that are obviously wrong, please let us know. We
        will make the necessary changes.</p>
      <p>See the
        <a href="http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt">SQL
        92</a> spec for the complete list and description of SQL state
        codes.</p>
      <p><a href="#">^ top ^</a></p>
      <p class="question"><a name="batchProcessing"></a>Batch processing
        using executeBatch() hangs or is unreliable on Sybase.</p>
      <p>When executing large batches on Sybase the client application may
        hang or the response time may vary considerably. The client may be
        suspended if the system log fills so check that the log space is
        sufficient for the batch you are trying to load. You can control the
        real batch size using the <code>batchSize</code> parameter; setting it
        to a non-zero value will break up batches into smaller pieces on
        execution, hopefully avoiding the problem.
      <p>It is also recommended that you execute each batch in a transaction
        (i.e. with auto commit set to false).
      <p><a href="#">^ top ^</a></p>

      <p class="title">Incorrect Behavior</p>
      <p class="question"><a name="callableStatementOutput"></a>
        <code>CallableStatement</code> output parameter getter throws
        <code>java.sql.SQLException: &quot;Parameter <i>X</i> has not been
        set.&quot;</code>.</p>
      <p>When executing a stored procedure (or any query, for that matter) the
        response from the SQL Server is serialized in the same order it is
        executed in: for stored procedures this means <code>ResultSet</code>s
        and update counts first, output parameters and return value last. jTDS
        only caches update counts , not <code>ResultSet</code>s because they
        could easily cause <code>OutOfMemoryError</code>s or add important
        performance overheads if cached to disk (the response would have to be
        parsed twice, for example).
      <p>As a conclusion, when executing stored procedures that only return
        update counts output parameters will be available immediately, as jTDS
        will process and cache the whole response. But if the stored procedure
        returns at least one <code>ResultSet</code> jTDS will only cache the
        update counts up to the first <code>ResultSet</code> and you will have
        to call <code>getMoreResults()</code> to process all the results. So
        for procedures returning <code>ResultSet</code>s you will have to loop,
        consuming all results before reading the output parameters (i.e. until
        <code>getMoreResults()</code> returns false AND
        <code>getUpdateCount()</code> returns -1).</p>
      <p>In case you are wondering if this is right, this is a quote from the
        <code>CallableStatement</code> API documentation: "For maximum
        portability, a call's <code>ResultSet</code> objects and update counts
        should be processed prior to getting the values of output
        parameters". Although this means that a "good" driver could "fix" this
        behavior, fixing it would imply caching the whole server response,
        equaling a huge performance drop.</p>
      <p>The exception is thrown because it's better to warn the user that the
        output parameters are not yet set instead of leaving the impression
        that all is ok and cause other, harder to detect problems.</p>
      <p><a href="#">^ top ^</a></p>
      <p class="question"><a name="lastUpdateCount"></a>
        <code>PreparedStatement.executeUpdate()</code> returns an incorrect
        update count.</p>
      <p>This is caused by triggers; replication is also implemented through
        triggers, so you will encounter this issue on replicated databases too.
        The root cause is that triggers also return update counts and jTDS can't
        make the difference between these update counts and the &quot;real&quot;
        one (neither could any other SQL Server client). However, the update
        count you need is the last of them (because the actual
        <code>UPDATE</code>/<code>INSERT</code>/<code>DELETE</code> gets
        executed only after the triggers) and there is luckily a parameter you
        can specify in the URL (or the connection <code>Properties</code> or in
        the <code>DataSource</code>) in order for jTDS to return only this last
        update count (and ignore the rest of them). This parameter is
        <code>lastUpdateCount</code> and you can find out more about it
        <a href="#urlFormat">here</a>.</p>
      <p>Please note that setting <code>lastUpdateCount</code> to
        <code>true</code> could cause problems if you use queries that do
        actually return more than one update count (such as queries consisting
        of multiple updates/inserts), because it will also return only the last
        of these update counts. Although queries returning multiple results are
        not very common, it is the reason why this behavior is customizable from
        the URL. Please note that this flag only alters the behavior of
        <code>executeUpdate()</code>; <code>execute()</code> will still return
        all update counts.</p>
      <p>If you have both queries consisting of multiple
        <code>UPDATE</code>s/<code>INSERT</code>s/<code>DELETE</code>s and
        triggers you won't be able to set <code>lastUpdateCount</code> to
        <code>true</code> if you want all the update counts, so you will have to
        skip over the irrelevant update counts by calling
        <code>getMoreResults()</code> yourself, when needed.</p>
      <p><a href="#">^ top ^</a></p>

      <p class="question"><a name="badrpccall"></a>
        Why do I get <code>java.sql.SQLException: "Output parameter not allowed
        as argument list prevents use of RPC."</code> when calling a stored procedure?</p>
      <p>When calling a stored procedure that has output parameters, the driver
         has to call the procedure using a remote procedure call (RPC). Stored
         procedures should be invoked using the special JDBC call escape syntax.
         For example, {call sp_example(?,?)}. In this case the driver will be able
         to use an RPC succesfully as all the parameters are represented by
         parameter markers (?). If however parameters are supplied as a
         mixture of parameter markers and literals, for example {call
         sp_example('test',?)}, then the driver is unable to use an RPC
         and therefore cannot return output parameters. In these circumstances the
         driver raises an exception and execution fails.</p>
         <p>It is possible to use mixed parameter lists to call stored procedures
         that do not have output parameters. In this case the driver will substitute
         the parameters locally and use a normal &quot;execute procedure&quot; SQL
         call; however, this mode of execution is less efficient than an RPC.
         </p>
      <p><a href="#">^ top ^</a></p>

      <p class="title">Memory Usage</p>
      <p class="question"><a name="preparedStatmentMemoryLeak"></a>Memory usage
        keeps increasing when using generated <code>PreparedStatements</code>.
        </p>
      <p>Normally, with a JDBC driver, <code>PreparedStatement</code>s are
        precompiled on creation, which gives increased performance if they are
        used a sufficient number of times. jTDS takes this one step further:
        when you create a PreparedStatement, jTDS caches it internally and keeps
        it there even after you close it so that every time you create it again
        it doesn't need to be recompiled, it's just fetched from the cache. This
        gives jTDS a 2x performance increase over the next fastest driver in
        some (not so uncommon) cases. For example, if you have a method that
        inserts a row into a table by creating a <code>PreparedStatement</code>,
        using it once and then closing it, your statement will be compiled only
        once for each <code>Connection</code>, no matter how many times you
        call that method.</p>
      <p>The number of statements that are kept open simultaneously can be
        controlled with the <code>maxStatements</code> parameter; see the
        <a href="#urlFormat">jTDS URL format</a> for more information.</p>
      <p><a href="#">^ top ^</a></p>

      <p class="title">TDS Protocol Version</p>
      <p class="question"><a name="getConnectionHangs"></a>I'm trying to connect
        to SQL Server 6.5, but it hangs when calling <code>getConnection()</code>.</p>
      <p>jTDS uses by default TDS 8.0 (which is SQL Server 2000's protocol) to
        communicate with the database server. When jTDS sends the 8.0 login request
        SQL Server 6.5 doesn't understand it so it returns a 4.2 error (<code>Login
        failed</code>). But because jTDS is expecting a TDS 8.0 packet as a response
        (not a TDS 4.2 packet) it doesn't properly understand the response packet
        and it hangs waiting for more data from the server. The solution is to set
        the <code>&quot;TDS&quot;</code> property to <code>&quot;4.2&quot;</code>
        (through the URL or <code>Properties</code> object passed to <code>getConnection()</code>
        or using the appropriate setter of <code>JtdsDataSource</code>, if you
        are using the <code>JtdsDataSource</code>).</p>
      <p>For more information about URL format and the properties that may be
        passed to jTDS have a look at the <a href="#urlFormat">jTDS URL format</a>.</p>
      <p><a href="#">^ top ^</a></p>
      <p class="question"><a name="longColumnNames"></a>Why do column names more
        than 30 characters long, get chopped off at 30 characters?</p>
      <p>You are very probably using TDS 4.2 to communicate with the SQL Server.
        TDS 4.2 is the protocol used by SQL Server 6.5 and it has the limitations
        of SQL Server 6.5 (among which a maximum column name size of 30 characters).
        jTDS 0.2 and earlier use TDS 4.2 by default. In order to change that you
        have to specify it explicitly in the <code>Properties</code> or the URL
        you supply when you create the connection. If you experience this problem
        with versions 0.3 or later, then you have specified (in the connection
        properties or URL) that TDS 4.2 should be used; remove that setting.</p>
      <p>For more information about URL format and the properties that may be
        passed to jTDS have a look at the <a href="#urlFormat">jTDS URL format</a>.</p>
      <p><a href="#">^ top ^</a></p>
      <p class="question"><a name="imageData4k"></a>jTDS fetches only the first
        4Kb of <code>IMAGE</code> data.</p>
      <p>You are very probably using TDS 4.2 to communicate with the SQL Server.
        TDS 4.2 is the protocol used by SQL Server 6.5 and it has the limitations
        of SQL Server 6.5 (among which a maximum size for <code>IMAGE</code> data
        of 4Kb). jTDS 0.2 and earlier use TDS 4.2 by default. In order to change
        that you have to specify it explicitly in the <code>Properties</code>
        or the URL you supply when you create the connection. If you experience
        this problem with versions 0.3 or later, then you have specified (in the
        connection properties or URL) that TDS 4.2 should be used; remove that
        setting.</p>
      <p>For more information about URL format and the properties that may be
        passed to jTDS have a look at the <a href="#urlFormat">jTDS URL format</a>.</p>
      <p class="question"><a name="connectOmnibus"></a>What do i have to do to connect 
        to Netcool Omnibus (or any derived Product).</p>
      <p>You are required to use TDS 5.0 to communicate with the Omnibus Server and
        set a default charset to avoid SQL errors, so your URL will look like: 
        <code>jdbc:jtds:sybase://NCO:4100;TDS=5.0;charset=iso_1</code>.
		Since the Omnibus Server understands only a limited subset of SQL, you cannot
		use prepared Statements.
		</p>
        
      <p><a href="#">^ top ^</a></p>

      <p class="title">Technical support</p>
      <p class="question"><a name="techSupport"></a>Is there any commercial
        technical support available for jTDS?</p>
      <p>For the moment you can get technical support from individual
        developers of jTDS. Of course, we will keep
        offering support on our SourceForge forums just as we did until now.</p>
      <p><a href="#">^ top ^</a></p>

      <p class="title">Other</p>
      <p class="question"><a name="other"></a>I didn't find the answer to my
        problem in this FAQ. What should I do?</p>
      <p>If you need help with any other jTDS-related issue, search the
        <a href="http://sourceforge.net/forum/forum.php?forum_id=104389">Help
        forum</a> first and if you still don't find anything, post a question.
        One thing, though: please
        register as a SourceForge member and log in if you haven't done so yet,
        so you can be automatically notified of updates to the questions you
        post.</p>
      <p>If you encountered an issue that you have tested and retested and you're
        sure it's a bug, use the Bugs link on top of the page. Again, make sure you
        are a SourceForge member AND that you are logged in when you post.
      <p><a href="#">^ top ^</a></p>


<!--
==================================
  Content ends here
==================================
-->

    </td>
    <td width="9" background="images/mainr.gif"><img src="images/spacer.gif"></td>
  </tr>
  <tr>
    <td width="9" height="9"><img src="images/mainbl.gif" width="9" height="9"></td>
    <td height="9" background="images/mainb.gif"><img src="images/spacer.gif"></td>
    <td width="9" height="9"><img src="images/mainbr.gif" width="9" height="9"></td>
  </tr>
  <tr>
    <td colspan="3">
      <table border="0" cellspacing="0" width="100%" class="outer">
        <tr>
          <td class="copyright" width="150">
            Project hosted by<br><br>
            <A href="http://sourceforge.net/projects/jtds" target="_top"><IMG src="http://sourceforge.net/sflogo.php?group_id=33291&amp;type=2" border="0" alt="SourceForge Logo" class="otherLogo"></A><br>
          </td>
          <td width="500"/>
          <td class="copyright" width="150">
            Web Design<br><br>
            <a href="http://anca13.go.ro" class="outer">Anca Sinpalean</a>
          </td>
        </tr>
      </table>
    </td>
  </tr>
</table>
</body>
</html>
